同一張架構圖，開發人員看到的是功能；架構師看到的是資料、關係，以及背後可能存在的風險。

一張架構圖，是架構分析的起點

在實務工作中，架構師每天面對的情境，並不一定都是從頭開始設計一套新的系統。更多時候，是有人拿著一張系統架構圖，希望協助確認設計是否合理。

例如，系統準備上線之前，希望進行一次架構審查；既有系統準備搬遷到雲端，希望重新檢視整體設計；或是新功能即將導入，希望評估是否會影響原有架構。

因此，架構分析真正的起點，就會先從需求開始，先瞭解這張架構圖所描述的內容，再進一步判斷哪些地方值得深入確認、哪些設計可能存在風險，以及哪些重要資訊尚未被呈現。

對架構師而言，一張架構圖所呈現的，不只是系統由哪些元件組成，更反映了資料如何流動、系統如何互動，以及整個平台背後的設計思維。也因為如此，學會閱讀架構圖，往往就是架構分析的第一步。

以資料流建立架構脈絡

每一位架構師閱讀架構圖的方法都可能不同。有人會先了解系統元件，有人會先確認使用者如何操作系統，也有人會先從網路架構開始分析。這些方式都沒有絕對的對錯，而是取決於架構師希望先理解哪一個面向。

在實際進行架構分析時，資料流（Data Flow） 通常是一個很適合的切入點。因為資訊系統存在的目的，並不是單純部署虛擬機器或建立資料庫，而是讓資料能夠被建立、傳遞、處理、儲存以及使用。順著資料流動的方向閱讀，可以逐步理解系統如何運作，以及不同元件之間為什麼需要建立這些關係。

因此，可以先從幾個基本問題開始：資料從哪裡進來？經過哪些元件？在哪裡完成驗證？在哪裡進行處理與儲存？又如何提供給其他系統或使用者？當這些關係逐步串接起來，原本分散的元件就會開始形成完整的架構脈絡。

資料流並不是唯一的架構分析方法，但它能夠協助架構師快速建立系統的整體脈絡，並進一步找出需要深入確認的區域，例如信任邊界、資料保護、權限控制、網路連線以及系統間的依賴關係。

開發人員與架構師，看的是不同的事情

不同角色閱讀同一張架構圖，關注的重點自然不同。

對開發人員而言，架構圖最重要的目的，是確認系統如何完成需求。因此，他們通常會關注系統由哪些元件組成、API 如何互相呼叫、資料如何存取，以及各個元件如何共同完成業務流程。

如果請一位開發人員畫出一張架構圖，通常會看到 Application、API、Database、Message Queue 等元件，以及它們之間的互動關係，藉此說明系統如何完成需求，以及不同元件如何共同支撐整個業務流程。

圖 13-1　開發人員視角（Implementation View）：從功能實作理解架構

因此，當開發人員閱讀或描繪架構圖時，通常會從功能實作的角度思考，例如：

• 如何完成使用者需求？
• API 應該如何設計與呼叫？
• 資料如何被存取？
• 元件之間如何協作才能完成整個流程？

這些問題都圍繞著系統如何運作。對開發團隊而言，最重要的任務，就是將需求正確地實作成可以運作的系統，因此架構圖也自然會以功能流程與元件互動作為主要描述重點。

架構師閱讀的是系統之間的關係

架構師閱讀同一張架構圖時，關心的則是另一個層面。

除了系統有哪些元件之外，更重要的是理解資料如何流動、不同系統之間如何建立關係，以及這些互動背後代表哪些設計考量。因此，同樣一張架構圖，在架構師眼中看到的，往往不是單一元件，而是整個系統如何共同運作。

圖 13-2　架構師視角（Relationship View）：從資料流與系統關係理解架構

因此，架構師閱讀架構圖時，應該要這樣思考：

• 資料流是否合理？
• 哪裡開始需要身分驗證與存取控制？
• 哪些地方跨越了信任邊界（Trust Boundary）？
• 資料在傳輸過程中是否需要加密？
• 不同系統之間是否存在過度依賴？
• 如果其中一個元件失效，是否會影響整個系統？
• 這張架構圖是否已經提供足夠的資訊，協助理解整體設計？

與開發人員相比，架構師並不只是確認功能是否能夠完成，而是希望透過架構圖理解整個系統如何協同運作，以及不同設計之間彼此會產生哪些影響。也因為如此，架構師更容易從整體的角度思考安全、可靠度、治理與維運等議題，而不只是單一功能是否可以正常運作。

不過，當架構逐漸複雜之後，單純依靠個人的經驗閱讀架構圖，往往很難確保所有重要的關係都被考量。 如果不同成員採用不同的方式理解資料流、信任邊界與系統互動，最後對同一套架構也可能產生不同的判斷。

因此，除了建立架構師的閱讀視角之外，團隊還需要一套共同的分析方法，讓不同角色能夠用相同的方式理解架構、討論風險，並在設計階段找出需要處理的問題。

Threat Modeling 建立的是共同的思考方式

威脅建模（Threat Modeling） 所扮演的角色，就在這裡。

許多人第一次接觸威脅建模時，會認為它是一套查找哪裡可能產生漏洞的方法。然而，威脅建模更重要的價值，在於提供一套共同閱讀與分析架構的方法。

當大家開始一起追蹤資料流，就會自然思考每一個環節需要哪些架構能力支撐。例如，資料在網路傳輸時是否需要使用 HTTPS、SSH 或 FTPS 保護內容；資料儲存在資料庫時是否需要採用靜態加密；系統對外提供服務時是否需要透過 Load Balancer 建立高可用性；不同系統交換資料時，又是否需要重新思考身分驗證、授權以及存取控制。

這些問題並不是等到系統完成之後才開始補強，而是在架構設計階段就應該納入思考。

因此，威脅建模帶來的不只是風險分析，更是一套將架構視角轉化為具體分析方法的方式。當團隊開始習慣從資料流、系統關係以及信任邊界閱讀架構圖，就能更容易理解每一項架構能力存在的原因，也更容易在設計初期發現潛在問題。

架構師真正的工作，也不是替團隊找出所有問題，而是協助團隊建立這種思考方式，讓每一位參與系統設計的人，都能理解每一項架構決策背後的原因。

小結

同一張架構圖，不同角色看到的重點往往不同。

開發人員著重於如何完成功能，因此自然會從系統實作與元件互動的角度理解架構；架構師則需要進一步理解資料如何流動、系統之間如何建立關係，以及整個平台是否已經具備支撐企業長期運作所需要的各項能力。

因此，閱讀架構圖的目的，不只是理解圖上畫了哪些元件，更重要的是理解這些元件如何共同支撐整個系統，以及哪些重要資訊尚未被描述。當能夠從這個角度閱讀架構圖時，看到的就不再只是系統本身，而是整個企業架構的設計思維。